Subject: Arch. item 8265

From: [email-masked]
Date: Thu, 13 Jul 95 10:19:11 EDT

Date: 10 July 1995, 09:11:12 EDT
From: Candy Elder                                    CANDACE  at RALVM6
      (919)254-4113; FAX (919)254-5410
      IBM C74A/B664  800 Park Offices Dr., RTP, N.C. 27709
      APPN Architecture
      IBMmail: USIB5ZBV at IBMMAIL
      Internet: [email-masked]
To:   aiw-appn-reference at www.raleigh.ibm.com
Subject: APPN arch. items 8264, 8265, 8266

Re: Note from you attached below

Tim,
      See my comment preceded by >>>>, imbedded in section 'arch8265 comments'
of your note below.
Regards, Candy

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Yep, I got Howard's note and didn't tell Ralph about it before he sent his
note to this list.  This is my fault.  So.....let's talk about these items.

Thanks for the comments, Howard....I've imbedded my comments in your note,
they're prefixed with the '>>>' tag.

Please respond with any further comments.

Tim,
  Here are some comments from the 3Com folks. Sorry they are kind of
  late.

Howard Blevins
3Com Corp
(408) 764-6985

Comments for all three documents:

1) Are they optional or manditory?

>>>8264:  because it is a fix to a known problem, it's a requirement for
>>>"future" APPN releases.  One part, however, is an option.  It's optional
>>>for DS to supply TRS the session COS and tail vectors on the QUERY_CPNAME
>>>signal.  This eliminates a redundant route calculation required of TRS if
>>>the DLU name does match the CP name of an active NN.  This is documented
>>>more clearly in the change pages if anyone needs more clarification on
>>>this.

>>>8265:  This is another fix to a known problem, so this is also required
>>>of "future" releases.

>>>8266:  This is an implementation option.  The function represents a feature
>>>that can be beneficial to customers managing APPN networks.  It's up to
>>>each implementation to decide how beneficial.

2) What version of APPN will they be apart of?

>>>I've been purposely vague about what "future" releases means.  Since we
>>>haven't officially published a new document for the APPN architecture in
>>>about 2 years, it's difficult to name an exact date.  All products, however,
>>>do know when these items become an official part of the architecture, so
>>>it's left up to their discretion, customer interest, etc..  This is not
>>>an official IBM stand, just my view of how the process is currently
>>>working.  The AIW members, of course, can have a lot to say here should
>>>you feel it's necessary.

arch8264 Comments:
1) For Figure 8-14 NN(OLU) Search logic, we felt that the changes you
made were not necessary. When you search the directory database, if
the resource is "not found" or is known to be a NN, then check the topology
database. If the resource is found (i.e it is a NN) then you are done. It
was not clear why you added the "search that node" leg of off the
"check topology database"

>>>This leg (leg from check tdb to search that node labelled other domain
>>>resource not in database) basically means that if the DLU name had been
>>>cached in the directory database, associated with another network node
>>>(other domain resource), but is not an NN itself, then send a directed
>>>Locate to that NN instead of doing a broadcast.  This is a feature that
>>>has always been a part of the architecture, and was not added due to this
>>>item.  For some reason, it was overlooked when this diagram was originally
>>>created, so we decided to add it in.

>>>The reasons why the TDB is checked for these cases are:
>>>  - the cached LU name may have matched the CP name of the associated NN,
>>>    so QUERY_CPNAME is issued to verify that the node is still an NN.
>>>  - if the cached LU name is different than the CP name of the associated
>>>    NN, it is still possible that that LU name represents an EN that
>>>    recently changed its node type to NN, so again TRS is checked for this
>>>    case.

2) Page 8-82, QUERY_CPNAME(RSP), origin endpoint TG vectors may or may not
>>> yep, you're right.  If the OLU resides on the NN itself or (I believe)
>>> for certain border node cases, origin TG vectors may not be supplied in
>>> the request.  We'll change the wording of this.

3) Page 8-83, QUERY_CPNAME(RQ), "If DS finds a destination NAU is not
in its domain (i.e. ...) or cannot find the destination NAU" Should really be
"If DS cannot find the destination NAU".
>>> no, see the "leg" discussion above for why a QUERY_CPNAME is still sent
>>> to TRS for these conditions.

arch8265 Comments:
1) Where is the format for CPDB006? We assume it will be added to the
MS Arch Ref.

>>>Good point....the format for this Alert will be added to the MS arch. ref.
>>>and as soon as its done they'll be provided to you.

2) On page 7-34, 3rd paragraph, the sense code for the DEACTIVATE_CP_CP_SESSION
needs to be specified. We assume you meant to use 0x081d005; however, that
is not clear in the document.

>>>The intent was not to include the sense code on the DEACTIVATE_CP_CP_SESSION
>>>signal, since it is already being supplied on the Alert signal that is
>>>also generated.  But on second thought, there may be benefit in doing this.
>>>It allows the node to communicate to the partner node why it is
>>>deactivating its CP-CP session with that node.  So, maybe it should be
>>>added in.  Any comments?

>>>> SS expects the DEACTIVATE_CP_CP_SESSION signal from TRS, to carry a
>>>> sense code indicating the reason for the CP-CP session deactivation.
>>>> When the CP-CP sessions are deactivated, the UNBIND for each CP-CP
>>>> session carries the sense code indicating the reason for the
>>>> deactivation, to the adjacent node.  Once the CP-CP sessions are
>>>> deactivated, for its con-winner session, SS checks to see if the
>>>> sense code indicates a recoverable condition.  Currently, only two
>>>> sense codes on the DEACT_CP_CP SESSION signal are considered to be
>>>> recoverable.  All others are not recoverable.  Using sense code
>>>> X'081D 0005' would indicate a non-recoverable condition, which
>>>> is the desired outcome.

arch8266 Comments:
1) In general, this command does not do what we would like it to do. We
normally know the nodes we trust and don't know the ones that we don't
trust. It would be better if we could specify the node that we are not
going to restrict. For this reason, we feel it would be better to modify
the define_adjacent_node command and break down the authorization level
into two parts: authorized to establish CP-CP sessions and authorized
to do mode to cos mapping. We would need to add a command that determines
the default value for unknown nodes.

>>>It's easier, for migration purposes, for the default case for new releases
>>>having this function to be the same default case as older releases that
>>>don't have this function.  This requires some explanation.

>>>Current APPN NN releases normally accept the COS supplied by client ENs
>>>(if it is supplied) for session requests.  So this is the behavior our
>>>customers see.  Adding the DEFINE_CLIENT_NODE_RESTRICTION command allows
>>>customers who want to continue the same behavior (probably the majority)
>>>to not have to do any extra configuration when upgrading their APPN
>>>releases.  They won't use that command because they don't need it.

>>>But if you modify the DEFINE_ADJACENT_NODE command to have to explicitly
>>>say the client can use its own COS, then the default behavior changes
>>>so that the COS from client nodes is normally NOT accepted.  So our
>>>unwitting customers who have spent (possibly long) hours getting their
>>>networks finetuned perfectly, may have to reconfigure their networks
>>>to reach that same behavior, should they upgrade to new releases.

>>>My thinking is that those customers that really want to use this command
>>>should be the ones doing the extra configuration work, not the customers
>>>that do not need the function this command provides.  Besides, you can
>>>achieve exactly what you want by specifying addition(ALL) and then
>>>specify deletion(those nodes that you do wish to allow to use their own
>>>COS).

2) This command also seems to conflict with the current define_adjacent_node
command. What if a node is authorized and "all" has been specified
in define_client_node_restriction? If you stay with the
concept of define_client_node_restriction, then it has to be documented
on how it works with define_adjacent_node.

>>>It does probably seem confusing that it is not explained how this command
>>>works with the concept of "authorization".

>>>The DEFINE_CLIENT_NODE_RESTRICTION command operates independently of whether >>>client nodes are authorized or not.  It doesn't
>>>matter if a client node is
>>>authorized, this command can still restrict that node from using its own
>>>COS.

>>>Unauthorizing nodes, for the most part, really isn't being done today.
>>>The APPN concept of authorization is much too restrictive, and is not
>>>even commonly supported by APPN implementations because
>>>there is little difference between LEN nodes
>>>and unauthorized ENs.  You lose a lot of the dynamic abilities of APPN
>>>when unauthorizing ENs (they can't be searched, they can't register their
>>>LUs. their CP capabilities have to be manually defined on the NN server,
>>>etc.)  The DEFINE_CLIENT_NODE_RESTRICTION command is an effort to move
>>>away from the authorization support, by allowing operators to dictate
>>>which functions are to be restricted yet not hindering the dynamic
>>>abilities that APPN provides.

Forwarded message:
> From [email-masked] Mon Jun 19 12:32:57 1995
> Date: Mon, 19 Jun 1995 15:32:23 -0400
> Message-Id: <[email-masked]>
> Errors-To: [email-masked]
> Reply-To: [email-masked]
> Originator: [email-masked]
> Sender: [email-masked]
> Precedence: bulk
> From: [email-masked]
> To: [email-masked]
> Subject: Modified APPN Architecture items
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> X-Comment:  APPN Reference
>
> The change pages for three modifications to the architecture have been placed
> on the Networking file server.  The three modifications were presented as
> proposals at the last AIW APPN reference SIG meeting.  Modifications
> suggested by members at that meeting have been incorporated in the
> documents.  Members (i.e. you guys and gals) have until Monday, July 3rd to
> review the documents, at which time, I'll be requesting CP status approval from
> you.
>
> The change pages are located under directory aiw/appn/architecture.
>
>    arch8264.psbin   Verifying Session Reachability when Performing Topology
>                        Nonverify
>    arch8265.psbin   Detecting Duplicate CP names when one Node is a VRN
>    arch8266.psbin   New NOF Command to Allow Network Nodes to Ignore COS
>                        Supplied by Client Nodes
>
> Regards and Happy Reviewing,
> Tim
>
>